Allow stargates and transport rings to be moved by other mods.#211
Allow stargates and transport rings to be moved by other mods.#211Acuadragon100 wants to merge 5 commits intoPovstalec:stargatejourney-1.20.1from
Conversation
|
Okay, so currently I'm slowly moving away from a BlockEntity based system and I'm in the middle of rewriting a bunch of stuff in order to eventually allow a compatibility with Just Stargate Mod, as well as stuff like establishing wormholes in Stargates on Create contraptions. So I think it would be better to wait on this until the new system is more set in stone and isn't constantly changing based on what the dev making the Create addon for sgjourney needs. Dunno if you would be okay with making another pull request once I'm done with that. If not I would just take the ideas from the PR and bring them over to the new system (you still get full credit tho). Whichever you prefer. Also also, not that much of a big deal, but FYI development with all the latest stuff happens on the "development" branch, which is on 1.19.3 (if you wanna know why on such a forgotten version, it's because it's easier since I only need to port back to 1 version, 1.19.2, instead of 3 versions back or more, and I'll keep it that way until I abandon 1.19 altogether). |
|
Oh, that sounds cool! |
2 participants
This pull request allows stargates and transport rings to be moved by other mods.
The first issue is the fact that both stargates and transport rings only add themselves to the network when the block item is used, not when the block is placed. The way I tackled this was to make the onPlace function schedule a tick which would update the stargate or transport ring network position. I did consider IForgeBlock::onBlockStateChange, but that's forge-specfic, so we can't guarantee that all mods will call it properly (Valkyrien Skies Eureka does not seem call it when assembling a ship). Also, using onPlace will make a fabric port in the future slightly easier.
However, that will only work with mods that make sure to remove the structure before placing the new one. Other mods might place the new structure and then remove the old one. With the current implementation, this would cause both stargates and rings to disappear from the network completely when moved. So I added an extra function to both the transporter and stargate interfaces to check if it's at the same position, which is now checked whenever a stargate is removed. I set the default return value for these methods to true for backwards compatibility, but let me know if you think I should remove the default implementation.
Unfortunately, there is yet another issue. Because Valkyrien Skies (and by extension VS Eureka) does not move all blocks at once. Instead, it moves each block one by one. That means that with the current implementation, the stargate will delete itself before Valkyrien Skies can finish moving it. To fix this, I've changed the stargate removal function to schedule the stargate for deletion on the next game tick (using Mojang's official scheduler). To ensure it doesn't delete parts of the new stargate when moved only a short distance, it also checks each part if it is the correct one for that position before removing it. The one downside with this is that it might increase the probability of a duplication exploit being discovered in the future, but I don't really have any better ideas.
I should note that there is one minor issue remaining which I do not address. The stargate will always disconnect when moved, even if it was the receiving gate. This could theoretically be used as a tactic to stop someone from connecting by assembling the stargate as a ship and immediately connecting to another stargate.